一、引言：迁移的规模与背景
据 Anthropic 工程博客 2026 年 10 月 13 日发布的《Redesigning source control at Anthropic》，该公司已将核心单一代码库（monorepo）整体迁出 git，改用自研版本控制系统 Scion。该项目的实施周期为五个月，参与工程师共七名；除 Scion 本身之外，交付范围还包括代码评审工具 Antique、代码搜索与源码权限系统等配套设施。下文依据该文及其公开资料整理。
二、迁移动因：合并量增长与既有缓解手段的失效
迁移的直接触发因素是代码合并量的持续增长。据该文披露，2026 年 5 月，Anthropic 的 monorepo 平均每日合并约 2,500 次代码变更；至 9 月，该数值已超过 3 万次，官方图表给出的单日峰值为 9 月 9 日的 30,401 次。以 24 小时为窗口折算，约每 3 秒即有一笔变更进入主干。
图 1 2026 年 1 至 9 月 Anthropic monorepo 每日合并量曲线。图源：Anthropic 工程博客
压力还来自仓库规模。主分支历史接近 100 GB，压缩后的工作副本超过 25 GB。持续集成（CI）环节每日执行约 2,500 万次代码检出，该统计尚未计入开发者本机、智能体（agent）沙箱与研究任务；若按最直接的方式拉取，每日产生的 git 流量在 600 PB 以上。
对于上述压力，git 社区已有的缓解手段 Anthropic 均已采用，涵盖浅克隆（shallow clone）、稀疏检出（sparse checkout）、promisor 远程（promisor remote）、存放于对象存储的仓库快照，以及高峰时期同时运营的几百个内部 git 镜像。该团队指出，这些措施曾为迁移争取时间，但此后相继失效：内部镜像受单机磁盘与内存上限约束，当仓库规模超过单机容量后无法继续扩展；在两次刷新之间，仓库快照与主干前沿的距离持续拉大，冷启动耗时随之增加；在部分克隆（partial clone）上执行 diff、blame 等依赖历史的操作时，维护成本亦不断上升。
图 2 扩展 git 检出能力的典型部署：内部镜像与仓库快照。图源：Anthropic 工程博客
Anthropic 认为，问题根源在于使用方式偏离了 git 的原始设计假设。git 属于去中心化系统，每份克隆完整自包含，可在离线状态下计算 diff、读取历史与 blame、检出任意版本；对绝大多数代码库而言，这一取舍是恰当的，也是 git 成为行业标准的重要原因。Anthropic 与多数企业一样，将 git 作为集中式系统使用，仅维护一份权威副本；而访问该副本的客户端几乎全部是智能体与自动化任务，自启动至结束均处于在线状态。为维持实际很少被使用的离线能力，每一次访问都需支付完整仓库的复制成本。
据此，该团队提出的设计问题是：若从零开始设计源码控制系统，并将客户端永远在线作为初始前提，该系统将呈现何种形态。
三、六条设计原则
据该文表述，Scion 的设计参考了 Google Piper 与 Meta Sapling 在处理超大 monorepo 方面的经验，其确立的六条原则分别针对上述偏离。
客户端永远在线
Scion 的客户端与协议以服务端随时可达为基本前提，客户端按需获取数据，不在本地保留仓库全量内容。
客户端与服务端不对称
在 git 中，每个客户端本身即是一台完整的服务器。Scion 采用相反的职责划分：blame、提交创建、合并与变基均由服务端承担；客户端仅维护容量有界的本地对象缓存，负责生成工作副本文件、监听文件系统变化；本地计算量保持在较低水平。
查询全部服务化
blame、两笔提交之间的先后关系等查询均以 API 形式提供。CI 作业与内部工具无需各自持有本地仓库，二分排错、自动回滚一类流水线因此可以规模化运行。
一切水平可扩
仓库数据以分布式方式存放，各组件独立扩容，任何单一节点均不保存完整仓库。系统内不存在 packfile，因此也不存在打包与回收一类例行维护作业。
提交廉价、增量、无锁
提交、变基与合并均在服务端完成，系统内不存在 push 这一动作。创建提交的成本仅与变更自身的大小相关，与仓库整体规模无关。移动分支与标签等引用，只需对 Spanner 中单行记录执行一次比较交换（compare-and-swap），与提交操作彼此独立。
工作副本可选且稀疏
需要执行 diff 的任务可直接向服务端请求结果，无须检出；相当数量的写操作完全通过 API 完成。协议原生支持稀疏检出与虚拟化检出；在确实需要落盘时，仅按实际读取的文件产生开销。
四、实现机制：changeset、派生数据与三层读路径
变更集与写入路径
Scion 的基本工作单元称为变更集（changeset），其载体是预写日志（write-ahead log）中的一条记录。据该文对比，git 的 commit 保存的是指向一棵目录树的指针，changeset 保存的则是相对第一父节点发生变化的文件列表，以及指向对象存储中压缩文件的内容寻址（content-addressed）指针。该设计下没有 packfile 需要接收，不存在跨服务器加锁，也没有引用需要挪动，写入吞吐因此可以达到较高水平。该文脚注进一步说明，相对第一父节点存储属于刻意的选择：在采用主干式开发的 monorepo 中，使用者关注的是主线上的历史与 blame。
图 3 changeset 的结构：相对第一父节点变更的文件列表与内容寻址指针。图源：Anthropic 工程博客
派生数据
仅记录变化的 changeset 无法回答“某行代码最后一次由谁修改”这类问题。为此，Scion 由 changeset 递归计算出附加的数据结构，统称为派生数据（derived data），其中包括 blame、路径历史与提交图跳表。每类派生数据的取值均由父节点的对应取值推导得出，既可按需即时计算，也可延后计算。客户端无法观察这些数据结构的内部构成，底层实现的更替不影响客户端的行为。
三层读路径与拉取协商
读路径分为三层。客户端 scn 通过套接字与本节点的 scion-daemon 通信，daemon 以周期性刷新的快照为起点，仅访问同区域的 scion-cache，仅在缓存未命中时才查询权威的 scion-server，后者按需读取 Spanner 或云存储。三层共用同一套 RPC，客户端不感知拓扑结构；每层命中率均超过 99%，且各层不依赖长期状态，通过增加机器即可扩容。
图 4 Scion 的检出架构：scn、scion-daemon、scion-cache 与 scion-server 三层。图源：Anthropic 工程博客
拉取协商（pull negotiation）的方式亦随之改变。git 的协商要求客户端告知服务端本地已持有哪些对象，Scion 则仅表达所需内容：从根树开始，递归索取本地缺失的树与对象。每个请求针对一个不可变对象，任意缓存均可应答；响应中不含体积达数 GB 的 packfile，传输过程可中断并续传。
实测性能数据
官方图表给出了迁移后的实测数据。在开发环境中，status 操作耗时由 3.9 秒降至 19 毫秒，拉取最新代码由 87 秒降至 3.5 秒；在智能体环境中，新建 worktree 的耗时由 7.1 分钟降至 5.1 秒，单个变更请求在源码控制上花费的总时间由 34 分钟降至 3.7 分钟。基础设施的 CPU 与内存占用降至原 git 镜像方案的 1/200，仅 CI 一项即释放出 25% 的 CPU 容量。
图 5 原生 Scion 仓库的实测性能提升。图源：Anthropic 工程博客
五、工程师角色的变化
据该文描述，参与该项目的每位工程师均认为，Claude 当前在编码方面已强于自己。团队在获得 Claude Mythos Preview 的早期内部版本之后，安排其重写了最初由人工编写的导入管道：重写后内存占用降至 1/20，速度提升至 4 倍，导入顺序与数据结构的不变量均得以保留。
工程师负责系统层面的判断。Anthropic 的表述是，工程师的一项重要工作在于“对 Claude 说不”。智能体有时会为满足某一模式而破坏系统约束；迁移中，某套系统不查询评审工具，转为线性读取提交日志，强行推算一笔变更的合入时间。对抗式评审虽然有效，但容易过度防御，Claude 可能针对假想风险加入过多校验，需由工程师出面制止。工程师仍会审查每一笔变更，其重点已从逐行阅读代码转向审视改动的意图。
运维方式同样发生变化。团队在 Slack 中为每个关键组件运行一个仅负责健康度检查的 Claude 实例，命名为 superfans，该实例能够读取遥测与日志，捕捉传统告警难以发现的细微问题。行业惯例中的全局仓库锁无法适配智能体规模，团队因此放弃了合并队列，转为在合入之后、部署之前执行自动化测试，并接受并发冲突，因为 Claude 修复冲突通常比人工识别更快。
图 6 2026 年 1 至 9 月 Scion 与 Antique 代码库每周合并变更量。图源：Anthropic 工程博客
六、相关工作：Piper、Sapling 与 Jujutsu
Scion 并非首个面向超大 monorepo 的版本控制系统。Google 的 Piper 已支撑容纳几十亿行代码的 monorepo 多年，2016 年发表的论文《Why Google Stores Billions of Lines of Code in a Single Repository》是该领域的标准参考文献；据 Anthropic 工程博客提及，Piper 中的文件级访问控制、Clients in the Cloud 云上工作区以及配套的 Critique 评审工具，在 Scion 中均有对应设计。Meta 的 Sapling 以 Mercurial 的概念为出发点，于 2022 年底开源客户端，以虚拟文件系统和 Smartlog 著称，官方称其可服务于数千万文件规模的仓库。由 Google 工程师以 Rust 开发的 Jujutsu（jj）则选择了另一条技术路线：其与 git 仓库格式保持兼容，以操作日志和简化后的模型替代暂存区等概念，可作为 git 前端直接用于日常开发。
七、适用边界
据 Anthropic 说明，Scion 并非 git 的通用替代品，其适用性仅对巨型 monorepo 成立，前提是组织拥有数万名工程师，或存在成群智能体持续产出代码；此外，Anthropic 内部消耗的 token 总量远超一般企业愿意承受的量级。由于 Scion 与 git 的差异过大，采用方需将开发生命周期的每一环重新实现，Anthropic 目前没有发布公开版本的计划。
该团队预计，此类问题将在未来 6 到 12 个月内变得常见。就国内已公开的数据而言，相关指标尚不处于同一量级：中国信息通信研究院云计算与数字化研究所 2026 年发布的《驾驭工程》报告显示，67.3% 的软件相关企业已在生产环境中使用 AI，AI 代码生成工具的企业渗透率为 54.4%；腾讯披露其超过 5 万研发人员使用 AI 编程工具，AI 生成代码的占比超过 35%。相关解读文章指出，这类数字说明的是 AI 参与编写了多少代码，并不能说明每日有多少笔变更进入主干；两者之间还隔着评审、CI 与版本控制环节，而版本控制环节正是 Scion 所处理的问题域。
八、对 git 生态的提案与启示
面向 git 生态的提案
该文向 git 生态提出若干建议：git 服务端不必与客户端保持一致的工作方式；托管平台可以提供完整的服务端 RPC，也可以在各平台之间统一该接口；协商协议存在改进空间，稀疏与浅克隆特性应能配合使用。Anthropic 明确表示，希望与 GitHub、GitLab 以及开源社区就此合作。
对现有 git 使用方的启示
就使用现有 git 的团队而言，该文提出的判断目前即可部分采纳：客户端在多数时段处于在线状态，因此不必在每次交互时交付完整仓库；diff 与 blame 可以交由服务端回答；工作副本可按需稀疏物化。在现有 git 上，浅克隆、稀疏检出与 promisor 远程均为现成的起点。
参考资料
- Anthropic 工程博客：《Redesigning source control at Anthropic》，2026-10-13。https://anthropic.com/engineering/redesigning-source-control
- Google 论文：《Why Google Stores Billions of Lines of Code in a Single Repository》，2016。
- Sapling SCM 官方文档：https://sapling-scm.com
- Jujutsu 项目仓库：https://github.com/jj-vcs/jj
- 中国信息通信研究院云计算与数字化研究所：《驾驭工程》报告，2026。
- 海盗 Sharp：相关解读文章，2026-10-14，本文部分内容的转引来源之一。
